-
Notifications
You must be signed in to change notification settings - Fork 524
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(typescript): add support for "jsx: preserve" compiler option #2574
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do you need help to get it green?
load("@build_bazel_rules_nodejs//:index.bzl", "nodejs_test") | ||
load("//packages/typescript:index.bzl", "ts_project") | ||
|
||
# Ensure that a.js produces outDir/a.js, outDir/a.d.ts, and outDir/a.d.ts.map |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
comment looks out-of-date
# Ensure that a.js produces outDir/a.js, outDir/a.d.ts, and outDir/a.d.ts.map | ||
SRCS = [ | ||
"a.tsx", | ||
"b.jsx", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the second file is just redundant? reduce the test case to one file if that gives the same assertions/coverage
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea of the second file is to assert that jsx files are not transformed to js files (which happens if jsx is not set to preserve).
@@ -0,0 +1,10 @@ | |||
const assert = require('assert'); | |||
|
|||
console.log(process.argv) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
remove console.log ?
const files = process.argv.slice(2); | ||
assert.ok(files.some(f => f.endsWith('out/a.d.ts')), 'Missing a.d.ts'); | ||
assert.ok(files.some(f => f.endsWith('out/a.d.ts.map')), 'Missing a.d.ts.map'); | ||
assert.ok(files.some(f => f.endsWith('out/a.jsx'), 'Missing a.jsx.map')); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
missed some copy-paste here, the endsWith doesn't match the message
if (option === 'jsx') { | ||
return jsxEmit[options[option] as ts.JsxEmit] | ||
} | ||
if (typeof (options[option]) === 'string' && option !== 'jsx') { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
else if
rather than repeat the inverse of the jsx condition
8f321bf
to
f6e5fbe
Compare
@alexeagle Trying to get it to green :) I actually just refactored the approach a bit, there's now a "preserve_jsx" attribute instead of "jsx", since we just care about the "preserve" option. |
f6e5fbe
to
317e697
Compare
When tsc is instructed to preserve jsx, the emitted files have a .jsx extension for .tsx and .jsx inputs, which means ts_project needs to be aware of the option to properly define outputs.
317e697
to
c0300cb
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
at first my reaction was "it's semantically similar to just map jsx=foo from tsconfig into BUILD" but then thinking more, the common case of jsx=react would force people to add a line to their BUILD file. So I like your boolean attribute more.
Thanks for the fix!!
When tsc is instructed to preserve jsx, the emitted files have a .jsx
extension for .tsx and .jsx inputs, which means ts_project needs to be
aware of the option to properly define outputs.
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
The current behavior causes the
ts_project
rule to fail as it is expecting different outputs.Issue Number: N/A
What is the new behavior?
In the new behavior,
ts_project
is aware of thejsx
compiler option and sets output files accordingly.Does this PR introduce a breaking change?
Other information